RUNNING HEAD: ENTERPRISE ARCHITECTURE AS FIVE ACTIVITIES A Unified View of Enterprise Architecture as Five Activities

Lapalme describes enterprise architecture as if it implements one of three completely different viewpoints, however Burk at OMB described enterprise architecture as having three different levels. Related, the PMBOK describes three levels of management. Hite at GAO describes a fourth process of managing enterprise architecture itself. This paper presents a unified view, with five total enterprise architecture activities in the whole. Introduction There is an ancient story from the Indian subcontinent in which several men, either blind or in the dark, try to describe an elephant. Each describes a different thing, as they have different vantage points and touch different parts of the creature. None grasps the whole as a single being. Perhaps enterprise architecture sometimes has a similar problem. Burk at OMB (2006) suggests enterprise architecture has three levels. A Unified View of Enterprise Architecture as Five Activities Lapalme (2012) suggests enterprise architecture has three schools of thought. The Project Management Institute in the PMBOK V5 (PMI 2013) holds that there are three levels or types of management for initiatives (Concerning things that start and end, other than functional management of continuous processes). PMBOK Level or Type Description Portfolio Management “Portfolios have a business scope that changes with the strategic goals of the organization.” Program Management “Programs have larger scope and provide more significant benefits.” Several projects may be organized into a program. Project Management “A project is a temporary endeavor undertaken to create a unique product, service or result.” Figure 3 shows the 3 levels of management related to projects from PMI 2013. Figure 1 shows the 3 levels of enterprise architecture from OMB 2006. Figure 2 shows the 3 views of enterprise architecture from Lapalme 2012. A Unified View of Enterprise Architecture as Five Activities Hite at GAO (2010) produced a revision of the EAMMF (Enterprise Architecture Maturity Management Framework). This activity of reflective enterprise architecture self-examination is not mentioned by either Burk or Lapalme. One more concept from Burk (OMB 2006) is the “Performance Improvement Lifecycle”, an overarching process across enterprise architecture. Figure 5 shows the Performance Improvement Cycle from OMB 2006. I assert that enterprise architecture can be said consist of five activities. These form a unified whole, which may all be implemented, or some subset may exist in an enterprise. The first three are described variously by Burke (OMB 2006) and Lapalme (Lapalme 2010), in support of the three levels of management in the PMBOK (PMI 2013). The fourth is governance which ties these three together. The fifth is a reflective process of enterprise architecture self-improvement, or maturity management, as described by Hite at GAO. Figure 4 shows the reflective process of evaluating and improving enterprise architecture. A Unified View of Enterprise Architecture as Five Activities Figure 6 Enterprise architecture as 5 processes. Discussion An integrated view of enterprise architecture is possible, with five activities. In such a view Burk (OMB 2006), PMBOK V5 (PMI 2013) and Lapalme (Lapalme 2012) all describe aspects of the same three activities. Enterprise architecture supports management of transformation, and the PMBOK describes the management of transformation. These three activities are interconnected by governance processes. Hite describes a fourth thing that evaluates and improves all the above. The Enterprise or “Enterprise Integrating” activity, supporting portfolio level management: A Unified View of Enterprise Architecture as Five Activities “By definition, EA is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior leaders, managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible” Burk in (OMB, 2006). Scope: “The enterprise as a sociocultural, techno-economic system, including all facets of the enterprise (where enterprise IT is just one facet)” Lapalme, 2012. Purpose: “Effectively implement the overall enterprise strategy by designing the various enterprise facets (governance structures, IT capabilities, remuneration policies, work design, and so on) to maximize coherency between them and minimize contradictions” Lapalme, 2012. Burk indicates that (2006) maximizing coherency and minimizing contradictions occurs by funding overall investments containing programs and projects. Further the context of Burk (2006) is the FEAF (Federal Enterprise Architecture Framework), based on Spewak and Zachman, analyzing all aspects of the organization (who, what, where, when, how, why) and from different viewpoints. If there is any difference, it is that Lapalme emphasizes “enterprise A Unified View of Enterprise Architecture as Five Activities IT is just one facet” and Burk indicates IT is an enabler of enterprise transformation. Otherwise both describe optimization of the overall enterprise to achieve a strategy. The “Segment” or “Enterprise Ecological Adaptation” activity supporting functional management or program management: “By contrast, segment architecture defines a simple roadmap for a core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers” Burk in (OMB, 2006). Scope: “The enterprise in its environment, including not only the enterprise but also its environment and the bidirectional relationship and transactions between the enterprise and its environment” Lapalme, 2012. Purpose: “Help the organization innovate and adapt by designing the various enterprise facets to maximize organizational learning throughout the enterprise” Lapalme, 2012. If you accept that the “Bi-Directional Relationships” of Lapalme occur via a product line (via sales) or in a specific business function (like human resources and the hiring event), the two A Unified View of Enterprise Architecture as Five Activities views become very similar. Both seem to describe optimization of a single business function or product line, where coverage of the enterprise must occur in each function or line independently. The “Solution” or “Enterprise IT Architecting” activity supporting project management: “Solution architecture defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of a solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. The primary stakeholders for solution architecture are system users and developers“ – Burk in (OMB 2006). Scope: “The enterprise-wide IT platform, including all components (software, hardware, and so on) of the enterprise IT assets” Lapalme, 2012. Purpose: “Effectively execute and operate the overall enterprise strategy for maintaining a competitive advantage by aligning the business and IT strategies such that the proper IT capabilities are developed to support current and future business needs” Lapalme, 2012. Here Lapalme seems to describe one single IT platform for the enterprise; however there are many IT platforms in a large enterprise. This is inevitable, because if IT understands its proper role in life, i.e. its only purpose is the “enable”, then an IT Strategy and IT EA must exist however if it needs to, so it can accommodating any mission and business needs. Even a midsized enterprise will have several. These many platforms may be interconnected or not, which is A Unified View of Enterprise Architecture as Five Activities the point of architecture in some large part. If you accept that, the two views seem to be convergent. The missing audit and self-assessment activity: Neither Burk nor Lapalme cover the reflective activity of self-assessment or audit of enterprise architecture itself, and improvement of its processes to achieve maturity. This is a different kind of activity which must also occur. In this activity, as in other maturity models, processes and concepts are written down or reused and tailored, made a part of the organizational culture, and eventually put under continuous improvement ultimately guided by performance metrics. Ultimately, for process maturity, all of the Enterprise, including the IT EA and Solution pieces must succumb to Capabilities Analyses’ efforts, so proper assessment can be done on “real data” rather than estimations, and enterprise architecture is not an exception. In enterprise architecture the written concepts, mechanisms, relationships and processes are often called “frameworks” and in the Hite model (GAO 2010) you cannot achieve high levels of enterprise architecture without one or more of these. The activities may in fact have different frameworks, as illustrated by the separate assessment framework itself. Interconnected Activities and Governance: Figure 7 Repeated Performance Improvement Lifecycle from OMB 2006. A Unified View of Enterprise Architecture as Five Activities Are these three activities applied exclusively, one or another, by teams of different schools of thought? Or could they all be applied in the same organization at once, and interconnected? Burk suggests the later: “Segment architecture is related to EA through three principles: structure, reuse, and alignment. First, segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service. Second, segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies. Third, segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards, and performance measures” –Burk in (OMB 2006). “Solution architecture is commonly related to segment architecture and enterprise architecture through definitions and constraints. For example, segment architecture provides definitions of data or service interfaces used within a core mission area or service, which are accessed by individual solutions. Equally, a solution may be constrained to specific technologies and standards that are defined at the enterprise level” -Burk in (OMB 2006.). US Department of Defense conducts activities which could be seen as being segment architecture. These are the JCIDS (Joint Capabilities Integration Decision System) process which identifies new needs for the mission areas, with input from field commanders, and separately the BEA (Business Enterprise Architecture) which describes common elements driven A Unified View of Enterprise Architecture as Five Activities by business needs. These activities are related to what might be seen as solution architecture, the DODAF (Department of Defense Architecture Framework) descriptions of individual systems or “systems of systems” within individual programs. Recently a set of common repositories have been added to begin tracking the whole of all efforts, especially in IT, which might be further classified as enterprise level governance. In the US Department of Homeland Security individual projects are reviewed in governance for compliance with the enterprise standards. Individual architectures for a single function or segment also review solutions. I will describe a second mechanism through which these three enterprise architecture activities are connected by governance. In this second mechanism the performance of the organization is optimized. Business plans to improve a single business function are developed by segment architecture in support of that functions management or its transformative program’s management. These business plans are forwarded to the higher organizational portfolio management authority that reviews the business plan and selects the best for implementation. It then controls them through implementation and evaluates the results to see when and if some approach or asset must be retired or upgraded. Individual project managers are charged with implementing and are supported by solution architecture. Conclusions I suggest that there is a correlation between the concepts in Burk and Lapalme and the PMBOK. Further, I suggest that enterprise architecture consists of at least four things, conducted by A Unified View of Enterprise Architecture as Five Activities different persons, working in different parts of the organization and using different methods to achieve different ends. They are, however related. Burk’s level Lapalme’s School Meaning of “enterprise” Goal Enterprise Enterprise Integrating An enterprise is a large umbrella organization or corporation. Performance optimization of an organization Segment Enterprise Ecological Adaptation An enterprise is a single business functional area, like Human Resources, or a single product line. Performance optimization of a single business function (i.e. human resources or logistics) or a product line Solution Enterprise IT Architecting An enterprise is the set of activities within the scope of the architecture. Optimization of a single solution or system Adding the work of Hite at GAO we get four main activities within enterprise architecture: • One that optimizes the overarching enterprise • One that optimizes each business function or product line • One that optimizes each solution • One that optimizes enterprise architecture itself, reflectively These may work together in an enterprise, and sometimes do. They may be linked by governance processes. Partial implementations, excluding some activities, are also possible. Enterprise architects, when arguing that the different views of architecture make them different A Unified View of Enterprise Architecture as Five Activities and unrelated approaches are like the proverbial blind men examining the elephant, imagining one component part as the whole. Enterprise architecture consists of five activities. These form a unified whole, which may all be implemented, or some subset may exist in an enterprise. The first three are described variously by Burke (OMB 2006) and Lapalme (Lapalme 2010), in support of the three levels of management in the PMBOK (PMI 2013). The fourth is governance which ties these three together. The fifth is a reflective process of enterprise architecture self-improvement, or maturity management, as described by Hite at GAO. Figure 8 Enterprise architecture as 5 processes. There are several impacts to applying a unified view with identified parts. One of the main impacts is clarity, leading to fewer arguments resulting from comparisons of apples to oranges. Another is the ability to clearly describe the different parts and their interactions. Another is the possibility of A Unified View of Enterprise Architecture as Five Activities describing when all five are appropriate, and when some may be omittedas in small businesses. Finally, in large complex organizations, we can potentially understand that implementing just one of these is not a full enterprise architecture program, and that adding other parts may be desirable.